With the proliferation of software products and services, attempts have been made to codify and/or standardize the designing of software and software architecture. Examples include:
The Booch Method and Modeling Language (see “Object Oriented Analysis and Design” by Grady Booch);                James Rumbaugh and Associates' Object Modeling Technique (OMT);        the Object Oriented Software Engineering (OOSE) method by Ivar Jacobson; and        the Unified Modeling Language (UML) which combines the foregoing and industry best practices.        
The UML is a visual modeling language (with formal syntax and semantics) for communicating a model or conceptionalization. Thus the modeling language specification specifies modeling elements, notation and usage guidelines and not order of activities, specification of artifacts, repository interface, storage, run-time behavior and so forth. In general, at the modeling level a “problem” is posed in terms of a customer's needs and requirements and may be referred to as the business problem system. The software designer develops a “solution” software product and or service that addresses the problem. The UML syntax enables software designers to express (specify and document) the subject problems and solutions in a standardized manner, while the UML semantics enable knowledge about the subject system to be captured and leveraged during the problem solving phase. See “UML in a Nutshell” by Simon Si Alhir, published by O'Reilly & Associates, September 1998. As such, the UML enables the sharing of information (including prior solution portions) and extension (without reimplementation) of core object oriented concepts (analysis and design) during the iterative problem-solving process for designing software products.
The UML2 specification defines stereotypes contained within a profile and applied to a model as a method of providing lightweight metaclass extensions. This enables the use of domain-specific terminology and notation for a given extended metaclass. As defined in the specification, a stereotype must be owned by a profile which is applied to a model through a ProfileApplication instance added to the model's appliedProfiles collection.
Though applied stereotypes are intended to be lightweight extensions when compared to alternative methods in UML, they actually impose substantial overhead in both memory and run-time processing. In cases where the stereotype is used as a simple domain-specific label (i.e. it contains no owned properties), the overhead of stereotypes stands out.